

m THE UNITED STATES PATENT AND TRADEMARK OFFICE 



i,/WBfre application of: Tran 

Serial No.: 09/550,181 

Filed: April 14, 2000 

For: Method and Apparatus for 
Maintaining State Information for 
Web Pages Using a Directory Server 



35525 

PATENfT TRADEMARK OFFICE 
CUSTOMER NUMBER 



Group Art Unit: 2155 
Examiner: Wang, Liang-cbe A. 
Attorney Docket No. : AUS000078US1 



rPrrifirfltPnf]V1ainngl[nHpr^7r,F,R. § 1 

I hereby certify this correspondence is being deposited with the United 
States Postal Service as First Class mail in an envelope addressed to: 
Commissioner for gatents, P.O. Box 1450,^lexan4piC^ 22313-1450 on 
November 29, 




TT^ANSMTTTAT. DOrTIMFNT 

Commissioner for Patents 
P.O. Box 1450 
Alexandria, VA 223 13-1450 

Sir: 

ENCLOSED HEREWITH: 

Appeal Brief (37 C.F.R. 41 .37); and 
• Our return postcard. 

A fee of $340.00 is required for filing an Appeal Brief Please charge this fee to IBM Corporation 
Deposit Account No. 09-0447. No additional fees are believed to be necessary. If, however, any additional 
fees are required, I authorize the Commissioner to charge these fees which may be required to IBM 
Corporation Deposit Account No. 09-0447. No extension of time is believed to be necessary. If, however, 
an extension of time is required, the extension is requested, and I authorize the Commissioner to charge any 
fees for this extension to IBM Corporation Deposit Account No. 09-0447. 



Respectfully submitted, 




Duke W. Yee 
Registration No. 34,285 
Yee & ASSOCIATES, P.C. 
P.O. Box 802333 
Dallas, Texas 75380 
(972) 385-8777 

ATTORNEY FOR APPLICANT 



ocket No. AUS000078US1 PA TENT 

% IN THE UNITED STATES PATENT AND TRADEMARK OFFICE 



^^4aEiW?5fe application of: Tran § 

§ Group Art Unit: 2155 
Serial No. 09/550,181 § 

§ Examiner: Wang, Liang-che A. 
Filed: April 14, 2000 § 

§ 

For: Method and Apparatus for § 
Maintaining State Information for § 
Web Pages Using a Directory Server § 



Commissioner for Patents 
P.O. Box 1450 
Alexandria, VA 22313-1450 



rmififatf nf IMailins Tfnripr M C.F.R. § 1,8(a) 

I hereby certify this correspondence is being deposited with the 
United States Postal Service as First Class mail in an envelope 
addressed to: Comrpksioner for Patents, ^J*r(5r\Box 1450, 
Alexandria, VA 2211^450 on Noven 




APPEAL BRIEF (37 C.F.R. 41.37) 

This brief is in furtherance of the Notice of Appeal, filed in this case on September 28, 2004. 

The fees required under § 41.20(B)(2), and any required petition for extension of time for filing this 
brief and fees therefore, are dealt with in the accompanying TRANSMITTAL OF APPEAL BRIEF. 



12/07/2004 HGUTERfll 00000029 090447 09550181 
01 FC:1402 340.00 Dft 



(Appeal Brief Page 1 of 43) 
Tran -09/550,1 81 



RKAT. PARTY TN TNTFREST 



The real party in interest in this appeal is the following party: International Business Machines 
Corporation. 
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RET.ATKD APPEAT.S AND TNTFRFF.RENCES 



With respect to other appeals or interferences that will directly affect, or be directly affected by, 
or have a bearing on the Board's decision in the pending appeal, there are no such appeals or 
interferences. 
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STATUS OF n ATMS 



A. TOTAL NUMBER OF CLAIMS IN APPLICATION 

Claims in the application are: 1-11, 13-19 and 21-40 



B. STATUS OF ALL THE CLAIMS IN APPLICATION 

1. Claims canceled: 12 and 20 

2. Claims withdrawn from consideration but not canceled: NONE 

3. Claims pending: 1-11, 13-19 and 21-40 

4. Claims allowed: NONE 

5. Claims rejected: 1-11, 13-19 and 21-40 

C. CLAIMS ON APPEAL 

The claims on appeal are: 1-11, 13-19 and 21-40 
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STATTTS OF AMFNDMFNTS 



No amendments to the claims have been made after maihng of the Final Office Action dated 
June 28, 2004. 



(Appeal Brief Page 5 of 43) 
Iran -09/550,181 



STTMMAttV OF TT ATMFD STTRTFrT MATTFR 



An apparatus, system, method and computer program product for maintaining Web page 
state information even when the user moves from Web page to Web page are provided. The 
present invention also provides an apparatus, system, method and computer program product for 
storing Web page state information in a form that is secure and portable between a plurality of 
Web browser applications. 

With the present invention, a user's request, from a client device (220) for a Web page, 
from a web page server (230-250), is used to send a background request, i.e. from a background 
application running on the client device (220), for Web page information from a directory server 
(260). The directory server (260) stores Web page state information for Web pages visited by the 
user that requires a user's input. If the requested Web page information is stored in the directory 
server (260), the Web page information is downloaded to the user's client device (220) and 
inserted into the received Web page, from web page server (230-250) at the appropriate fields in 
the Web page (see specification, pages 7-8). 

In practice, when a user of a client device (220) enters a URL into a Web browser of the 
client device (step 710), a background request is sent from the background application (see 
specification, page 11, line 32 to page 12, line 8) to the directory server (260) (step 720). A 
determination is made as to whether information for the requested Web page is received from the 
directory server (step 730). If so, the received information is inserted into the Web page (step 
740). If not, the user's input and corresponding Web page field identifier are stored to the 
directory server (steps 750-760) (see also specification, page 13, line 6 to page 14, line 8) 

At the directory server, if a request for Web page state information is received (step 610), 
the directory is searched for the Web page information (step 620) and if found, the information is 
retrieved and sent to the requesting system (step 650). If no Web page state information is found, 
a new Web page entry in the directory server is created (step 640) for storing state information, 
i.e. user input and corresponding Web page field identifiers, from the background application 
(see specification page 12, line 9 to page 13, line 5). 

Figure 3 illustrates one exemplary embodiment of a computing device in which aspects of 
the present invention maybe implemented. As described on pages 14-16 of the present 
specification, this computing device includes a processor (302), a network interface (either LAN 
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adapter 3 10 or modem 322), and a keyboard and mouse adapter (320). The processor 302 may 
execute instructions to receive user input via the keyboard and mouse adapter (320), send 
instructions from a background appUcation rurming on the processor (302) to a directory server 
via the network interface (LAN adapter 310 or modem 322), and send requests from the 
background application running on the processor (302) to the directory server to retrieve user 
input and a corresponding Web page field identifier. 
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nROTTNnS OF RF.TFrTTO N TO RF RFVTFWFD ON APPEAL 



The grounds of rejection to be reviewed on appeal are as follows: 

(1) Claims 1-7,9, 11, 13-18, 21-27, 29-33 and 35-40* are rejected under 35 U.S.C. § 
103(a) as being allegedly unpatentable over Larsen et al. (U.S. Patent No. 6,088,700) in view of 
Kavner (U.S. Patent No. 6,366,947); 

(2) Claims 8, 19, 28 and 34 are rejected under 35 U.S.C. § 103(a) as being allegedly 
unpatentable over Larsen et al. (U.S. Patent No. 6,088,700) in view of Kavner (U.S. Patent No. 
6,366,947) and further in view of Tomko (U.S. Patent No. 5,790,668); and 

(3) Claims 10 and 36 are rejected under 35 U.S.C. § 103(a) as being allegedly 
unpatentable over Larsen et al. (U.S. Patent No. 6,088,700) in view of Kavner (U.S. Patent No. 
6,366,947) and further in view of Call (U.S. Patent No. 6,154,738). 



* It is noted that although the statement of the rejection does not include claims 36-40, the body 
of the rejection includes a rejection of claims 36-40 (see page 6, section 18 of the Final Office 
Action) 
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nROTTPTNC OF TT.ATMS 



The claims do not stand or fall together for the reasons set forth hereafter in Appellant's 
arguments. The claims stand or fall according to the following grouping of claims: 



Group I; 


clamis 1, 1 J, 21, 2y, J /, ana jo, 


Lrroup 11. 


claims z, 14, zz, ana iU, 


/^■w^tir^ TTT- 

Lrroup 111. 


Claims 3, Ij, zJ ana ii, 


Group IV: 


claims 4, 16 and 24; 


Group V: 


claims 5, 17 and 25; 


Group VI: 


claims 6, 18, 26, and 40; 


Group Vn: 


claims 7, 27 and 33; 


Group Vm: 


claims 9, 35, and 39; 


Group IX: 


claim 1 1 ; 


Group X: 


claims 32; 


Group XI: 


claim 8, 19, 28, and 34; and 


Group XH: 


claim 10, and 36. 
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AttHTIMFNT 



L 35 TJ.S.C. § 103(3), Allfgfd Ohviniisnfss Claims 1-7, 1.V18> 21-27, 29-33 and 

The Final Office Action rejects claims 1-7, 9, 11, 13-18, 21-27, 29-33 and 35-40^ are 
rejected under 35 U.S.C. § 103(a) as being allegedly unpatentable over Larsen et al. (U.S. Patent 
No. 6,088,700) in view of Kavner (U.S. Patent No. 6,366,947). This rejection is respectfully 
traversed. 

Grniiping: riaims 1, 21, and is 

With regard to independent claim 1, the Final Office Action states: 

Referring to claim 1, Larsen has taught a method for maintaining state 
information for web page (see title and abstract), comprising: 

a. receiving user input to a Web page via a Web browser at a client device 
(abstract lines 3-4, fill out data field. . . multiple forms. . ..on the web browser of 
users... Col 2 lines 8-13, 30-33, Col 3 lines 28-30, Col 17 lines 14-16, the user 
input is used for future automatically form filling on the web page via a browser 
of users); 

b. sending an instruction to store user input and a Web identifier in a 
directory server (Col 2 lines 31-38, information entered by the user are stored in 
the database, and the forms are transmitted. , .are stored for later retrieval, updating 
and printing by the user; Col 3 lines 12-14, database is located in a server); 

c. storing the user input and a corresponding web page field identifier 
(Col 2 lines 31-38, information entered by the user are stored in the database, and 
the forms are transmitted. . .are stored for later retrieval, updating and printing by 
the user; Col 3 hnes 12-14, database is located in a server);); and 

d. in response to receiving a user request, via the Web browser, for the 
Web page, sending a request to the directory server to retrieve the user input and 
corresponding Web page identifier (Col 3 line 59-Col 4 line 8, Abstract lines 7- 
13), wherein the user input and corresponding Web page field identifier are 
retrieved from the directory server (abstract, Col 2, lines 8-11, 20-38.) 

Larsen has not taught the use of background application running on the 
client device to send instruction and request to directory sever to retrieve user 



It is noted that although the statement of the rejection does not include claims 36-40, the body 
of the rejection includes a rejection of claims 36-40 (see page 6, section 18 of the Final Office 
Action) 
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input and corresponding Web page field identifier. 

However, Kavner has taught a system which is able to download or send 
requests to update local cache information firom the server in the background (Col 
5 lines 16-19, 30-36, Col 11 lines 31-37). 

It would have been obvious to a person with ordinary skill in the art at the 
time the invention was made to incorporate this background process of Kavner 
into Larsen because both have taught inventions regarding to information retrieval 
fi-om a server to a client in a network communication environment. 

A person with ordinary skill in the art would have been motivated to make 
the incorporation to Larsen because it would allow user to get the benefit of being 
able to see the web page immediately while the resources that have changed since 
they were previously downloaded are updated in the background as taught by 
Kavner (Col 4 lines 56-59), and also would shift some burden fi"om the active 
application since some tasks are being assigned to the background application. 

Independent claim 1, which is representative of independent claims 13 and 21 with regard 
to similarly recited subject matter, reads as follows: 

1 . A method for maintaining state information for Web pages, comprising: 

receiving user input to a Web page via a Web browser at a client device; 

sending an instniction to store user input and a Web page field identifier in 
a Hireetory server from a haekgrnnnd application n mning on the client device; 

storing the user input and a corresponding Web page field identifier in the 
directory server; and 

in response to receiving a user request, via the Web browser, for the Web 
page, sending a request from the background application running on the client device to the 
directory server to retrieve the nser inpnt and corr esponding Web page field identifier, 
wherein the user input and corresponding Web page field identifier are retrieved fi-om the 
directory server, 
(emphasis added) 

Larsen teaches a system that automatically completes multiple forms for multiple 
companies or regulatory agencies by filling out information once on any form presented on the 
user's browser. With the Larsen system, a company must register its forms, which may then be 
populated with information entered by a user. The user in Larsen enters a form identifier and user 
input to be entered into the form. The data processing system retrieves tagged information 
previously entered by the user and stored in a database, and automatically inserts the data in 
similarly tagged uncompleted fields of any number and variety of registered forms (column 2, lines 
24-35). Larsen uses a Mapping Application to identify the forms, their fields and the clients 
subscribing to each form, and then map that information into a relational database. Larsen then 
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uses Web Form Filler that uses a web server that allows potential candidates or employees of a 
company to fill out the forms electronically (column 2, lines 8-12). 

Larsen does not teach or suggest sending an instruction to store user input and a Web page 
field identifier in a directory server fi-om a background application running on the client device or 
sending a request from the harkgronnH appliration nmning on the client devire tO the directory 
server to retrieve the user input and corresponding Web page field identifier. Larsen teaches at 
column 3, lines 61-67 that a Web user requests a form over the Global Information Network or 
Local Network and enters information on his or her display. The information is then transferred 
over the network to a Form Parser, which is a network server. However, Larsen does not mention 
anything about an application that is running in the background on the Web user's device or any 
background application that sends instruction to store user input and a Web page field identifier or 
sends request to retrieve the user input and corresponding Web page field identifier. 

With the background application of the presently claimed invention, a user thinks that he or 
she is visiting a Web page in a normal fashion, however, specific fimctions are performed in the 
background, in addition to the web page retrieval, to retrieve user input and a Web page field 
identifier and populate the Web page without the user's awareness. Larsen does not teach such 
features. To the contrary, Larsen teaches that a user has to request a form and enter information on 
his or her display. The system of Larsen also does not perform specific functions, such as sending 
an instruction in the background to store user input and a Web page field identifier in the directory 
server without user's request. 

The Final Office Action admits that Larsen does not teach using a background application 
at a client device to send instructions and retrieve user input and corresponding Web page field 
identifiers fi-om a directory server. However, the Final Office Action alleges that this feature is 
taught by Kavner. Appellant respectfiilly disagrees. 

Kavner is directed to a system that stores resources that have been requested, e.g., data 
representing HTML and images of web pages, to a local cache when the user first accesses a 
particular Web page. Subsequent requests by the user to access the same Web page are 
immediately drawn fi-om the local cache for presentation to the user, while simultaneously in the 
background a "get" request is sent to the server to download any changes since the previous 
loaded version is stored in the cache. While Kavner generally teaches using a background 
application to "get" data from a server, Kavner specifically teaches that the background 
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application is used to get a most current version of the requested resource, e.g., HTML and 
graphic images of a requested Web page (See, for example, Lines 44-59; Column 5, Lines 30- 
32). Kavner does not teach , suggest, or otherwise allude to using the background application to 
retrieve "user input and a corresponding Web page field identifier" from a directory server in 
response to receiving a user request via a Web browser. 

The Final Office Action states that Kavner teaches a system which is able to download or 
send requests to update local cache information from the server in the background at column 5, 
lines 16-19, 30-36 and at column 11, lines 31-37, which read as follows: 



The present invention, operating in the background of the loading of data 
from the local storage cache, sends a "get" to the server hosting a web site, and 
identifies changes since the previous load stored in the cache. . . 
(Column 5, Lines 16-19, Kavner) 

According to the present invention, during the second and subsequent 
accesses to a web page, any resources present in the local cache are displayed to 
the user immediately. In the background the present invention causes the GET 
<resource> requests to be issued to the server in order to update the cache and/or 
presentation to the user... 
(Column 5, Lines 30-36, Kavner) 

In order to provide the background tasking utilized by the present 
invention, it is desirable to have a multithreaded operating system. This is 
because the present invention relies on having several threads operating at the 
same time. By "thread" is meant a discrete software operation, which may include 
a plurality of sequential steps. . . 
(Column 11, Lines 31-37, Kavner) 

In these sections, Kavner only teaches using the background application to send data 
representing the requested resource, e.g., HTML and graphic images of a requested web page, to 
a local cache to be stored. The local cache is created on the local hard disk. Kavner does not 
teach or suggest a background application that sends an instruction to store user input and a Web 
page field identifier in a directory server, as recited in claim 1. Thus, despite the allegations 
made by the Final Office Action, Kavner in fact does not teach or suggest a background 
application rurming on a client device that sends an instruction to store user input and a Web 
page field identifier in a directory server. 

In addition, Kavner does not teach that, in response to receiving a user request for a Web 
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page, via a Web browser, a request is sent "from the background application running on the client 
device to the directory server to retrieve user input and a corresponding Web page field 
identifier." To the contrary, at column 10, line 62 to column 11, line 1, Kavner teaches that the 
system utilizes an intelligent cache to immediately present available information to a user while, 
in the background, determining if cached data has been updated on the network. If so, the system 
downloads the updated data to the local cache. The data that Kavner downloads is an update of 
the requested resource, e.g., updated HMTL Web pages and graphic images, not "user input" or 
"Web page field identifiers" corresponding to the retrieved user input. Thus, Kavner only 
teaches sending a request to retrieve updated HTML Web pages in response to determining that 
the cached data has been updated on the network. Otherwise, no request is sent in the 
background to a server for updated information. Kavner does not send a request from the 
background application to retrieve user input and Web page field identifiers responsive to 
receiving a user request for a Web page, as recited in claim 1. 

Thus, despite the allegations made in the Final Office Action, Kavner does not teach or 
suggest the features recited in claim 1 . Even the Final Office Action only states that Kavner 
teaches updating local cache information using a background application (Final Office Action, 
page 4, lines 4-6). Thus, it appears that the Examiner's position is that simply because Kavner 
teaches a background application to update a cache, even though Kavner does not specifically 
teach or suggest to use a background application to retrieve user input to a Web page that is 
stored in a directory server, and a corresponding Web page field identifier from a directory 
server, the specific features of claim 1 are taught by the alleged combination of Kavner and 
Larsen. Appellant respectfiiUy disagrees. 

Neither Larsen nor Kavner provide any suggestion to use the background application of 
Kavner to send user input and a Web page field identifier to be stored in a directory server or 
retrieve the user input to the Web page that is stored in a directory server and its corresponding 
Web page identifier. To the contrary, Larsen specifically teaches, at column 3, lines 61-67, that a 
Web User (12), company candidate or employee, requests a form over the Global information 
Network or Local Network and enters information on his or her device. The information is then 
transferred over the network to the Form Parser (13), which is a network server. The Form 
Parser (13) submits the request for the form and inputted data to the Form Database (3). Larsen 
does not teach that any background application exists on the Web user's device, or any other 
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application on the Web user's device, that sends and retrieves the user input and corresponding 
Web page field identifier. To the contrary, Larsen teaches that the Form Parser, which is 
implemented in a network server separate from the Web user's device, submits the request for 
the form, and input data from the Web user, to the Form Database. 

Larsen is only concemed with a network server, such as the Form Parser, that allows a 
user to complete multiple pre-filled forms for multiple companies or regulatory agencies. Larsen 
is not concemed with having a background application running in parallel with a Web browser 
on iha Weh user's Hevire ^ i.e. client device, that sends an instruction to store user input and Web 
page field identifier in a directory server and sends a request to retrieve user input and a 
corresponding Web page field identifier from a directory server. A person of ordinary skill in the 
art would not have been motivated to modify Larsen's teaching to include a background 
appHcation to enhance functionalities of a Web user's device because Larsen is only interested in 
enhancing functionalities outside of the Web user's device to assist in completing multiple 
forms. 

Moreover, as discussed above, Kavner teaches using the background application to 
update local cache HTML and graphic images for a Web page. Kavner does not even teach or 
suggest using the background application to store user input and a corresponding Web page field 
identifier in a directory server and then retrieve that user input and the corresponding Web page 
field identifier from the directory server in response to receiving a user request. 

Since neither reference teaches or suggests the above emphasized features of claim 1, the 
only source of such teachings or suggestions must necessarily come from a prior knowledge of 
Appellant's claimed invention and the sole purpose of trying to recreate Appellant's claimed 
invention using the elements described in Larsen and Kavner. This is clearly a combination that 
is based completely on a hindsight reconstruction of the claimed invention using Appellant's own 
disclosure as a guide. Thus, the rejection of claim 1 based upon the alleged combination of 
Larsen and Kavner is improper and should be overturned. 

Furthermore, the references are not combinable in the manner alleged by the Final Office 
Action. Larsen is directed to a system for automatically completing multiple forms for multiple 
companies or regulatory agencies. Kavner is directed to a system for storing data representing 
HTML and images to a local cache and updating that information when the Web page changes. 
There is no problem or deficiency set forth in either of Larsen or Kavner for which the other 
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reference is a solution. This is because the references are directed to solving different problems. 
One of ordinary skill in the art, when viewing the automatic form system of Larsen would not 
immediately determine that it would be beneficial to include a local cache storage system for 
HTML and image content of Web pages in the system of Larsen. Similarly, one of ordinary skill 
in the art when viewing Kavner would not immediately determine that it would be beneficial to 
include an automated form system, such as taught by Larsen, in the local cache system of Kavner. 

Even if a person of ordinary skill in the art were led to combine Larsen and Kavner, the 
resulting combination would still not result in a system or method in which an instruction to store 
user input and a Web page field identifier is sent to a directory server fi-om a background 
application running on a client device. Moreover, the alleged combination would not result in a 
system or method in which user input and a corresponding Web field identifier are retrieved fi"om 
a directory server using a background application on a client device, in response to a user request 
via a Web browser. Rather, the resulting combination would be a Form Parser on a network 
server that submits requests for forms to the Form Database and a background application 
running on a client that retrieves updated HTML Web pages. Therefore, it would not have been 
obvious to a person of ordinary skill in the art to combine Larsen and Kavner' s teachings, and 
modify them in the particular way that would be necessary, such that the result is a method that 
sends an instruction fi-om a background application running on a client device to store user input 
and a Web page field identifier in a directory server, without the disclosure of the Applicants. 
Furthermore it would not have been obvious to a person of ordinary skill in the art to combine 
Larsen and Kavner*s teachings, and modify them in the particular way that would be necessary, 
such that the result is a method that sends a request fi*om a background application running on a 
client device to a directory server to retrieve user input and a corresponding Web page field 
identifier from the directory server in response to receiving a user request. 

In view of the above. Appellant respectfully submits that neither Larsen nor Kavner, 
whether taken alone or in combination, teach or suggest the features recited in independent claim 
1. The other independent claims 13 and 21 recite similar subject matter and thus, are 
distinguished over Larsen and Kavner for similar reasons. 

In addition, neither Larsen nor Kavner, either alone or in combination, teach or suggest the 
specific features of independent claim 29. Independent claim 29, recites: 

29. A method, in a dirertnry server ^ for maintaining state information 
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for Web pages, comprising: 

receiving user input to a Web page frnm a har kgrmind application 
running on a rlient Hftvir.e; and 

Storing the user input and a corresponding Web page field 
identifier received from the har.kgronnd application running on the client device in 
the directory server ^ wherein the user input and corresponding Web page field 
identifier are downloaded from the directory server to the client device in response 
to a user request for a Web page, 
(emphasis added) 

Larsen does not teach or suggest a method in a directory server that receives user input to 
a Web page frnm a background application running on a client device. Larsen only teaches a 
system that receives a request from a user for a form over a Global friformation Network or Local 
Network and enters information on the user's display. Li the Abstract, Larsen teaches to use data 
stored in a database to automatically fill out data fields of the forms displayed on the Web 
browser. Larsen does not teach or suggest receiving user input to a Web page frnm a background 
application on the client device that stores user input and Web page field identifier in the 
directory server, as recited in claim 29. A background application is an application that runs in 
parallel with a Web browser and performs specific fiinctions in the background without a user's 
request. Larsen only teaches a display that allows a user to enter his or her information. Larsen 
does not teach a background application that runs in parallel with the display or a background 
application that stores user input and Web page field identifier in a directory server. Thus, 
Appellant submits that Larsen does not teach or suggest the specific features recited in 
independent claim 29. 

Li addition, while Kavner may teach using a background application to update HTML and 
images for a Web page in local cache, Kavner provides no teaching or suggestion regarding using 
a background application to store or retrieve "user input and corresponding Web page field 
identifier" to/from a directory server, such as recited in claim 29. Moreover, neither reference 
provides any teaching or suggestion to make the combination and necessary modifications to the 
combination of Larsen and Kavner that would be required to arrive at the claimed invention, as 
discussed above with regard to claim 1 . Therefore, the features of claim 29 are neither taught nor 
suggested by the alleged combination of Larsen and Kavner. 

With regard to independent claim 37 and dependent claim 38, neither Larsen nor Kavner, 
whether taken alone or in combination, teach or suggest sending an instruction, from a background 
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application running on a client, to a server to store user input to a Web page and an identifier 
associated with the user input. Larsen and Kavner also do not teach or suggest that, responsive to a 
subsequent request, via a Web browser for the Web page, a request is sent from a background 
application running on the client to the server to retrieve the user input and the identifier from the 
server. As discussed in the arguments presented above for claims 1,13 and 21, Larsen does not 
teach any background application running on the client that sends an instruction to store user input 
and identifier associated with the user input in a directory server, or that sends a request to retrieve 
user input and the identifier in response to a subsequent request for a Web page. Larsen only 
teaches that a user may request a form over the network and enters information on his or her display 
and the information is then transferred over the network to a Form Parser, which is a network 
server. There is no mention of a background application running on the client that performs 
specific functions, such as those mentioned in claim 37. Moreover, Kavner only teaches using a 
background application to update the HTML and images for a Web page in local cache and does 
not teach or suggest using a background application to store or retrieve user input and an associated 
identifier to/from a server. Thus, the alleged combination of Larsen and Kavner does not teach or 
suggest the features of claims 37 and 38 for similar reasons as noted above with regard to claims 1, 
13,21 and 29. 

At least by virtue of their dependency on claims 1, 13, 21, 29 and 37, respectively, neither 
Larsen nor Kavner, whether taken alone or in combination, teaches or suggests the features set forth 
in dependent claims 2-7, 9, 11, 14-18, 22-27, 30-33, 35, 36 and 38-40. In addition, Larsen and 
Kavner do not teach or suggest any of the specific features set forth in the dependent claims 2-7, 9, 
11, 14-18, 22-27, 30-33, 35, 36 and 38-40. 

firniiping: Claims 2 J 4, 22, and 30 

For example, with regard to dependent claim 2, which is representative of claims 14, 22 and 

30 with regard to similarly recited subject matter, neither Larsen nor Kavner teach or suggest that 

the user input and Web page field identifier are specific to a particular Web page. The Final Office 

Action alleges that Larsen teaches this feature at column 17, lines 25-29, which reads as follows: 

storing said uniquely registered form identifying information in said database, 

said registration means begin capable of assigning said form template a unique registration 

such that said form template becomes a uniquely registered form template. 

(Column 17, Lines 25-29, Larsen) 
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In the above section, Larsen teaches assigning a registration to a form template that is 
unique from other registered form templates. Thus, Larsen only teaches a registration that is 
specific to a form template. Larsen does not teach or suggest that both the user input and the Web 
page field identifier are specific to a particular Web page. Therefore, Larsen does not teach the 
features of claims 2, 14, 22 and 30. 

Grouping: riaims 1, 1 2\ and .^1 

With regard to dependent claim 3, which is representative of claims 15, 23 and 31 with 
regard to similarly recited subject matter, Larsen does not teach or suggest that the user input and 
Web page field identifier are common to a plurality of Web pages. The Final Office Action alleges 
that Larsen teaches this feature at column 17, lines 34-38, which reads as follows: 

said mapping means being capable of sorting said uniquely registered form identifying 
information into common group information, 

said common group information being stored in said database, 
(Column 17, Lines 34-38, Larsen) 

In the above section, Larsen teaches mapping means that include sorting identifying 

information that identifies a unique registered form into common group information, which implies 

that the identifying information may be sorted based on the common group information. However, 

Larsen does not teach that the user input and Web page field identifier are common to a plurality of 

Web pages. Larsen does not teach that the common group information includes a plurality of Web 

pages. Larsen also does not teach that the identifying information includes user input and Web 

page field identifier. Larsen only teaches that the identifying information identifies each uniquely 

registered form. In other words, forms may be grouped based on these identifiers. Larsen does not 

teach or suggest that user input and a Web page field identifier are common to a plurality of Web 

pages, as recited in claims 3, 15, 23 and 31. 

Grouping! riaims 4^ 16^ and 24 

With regard to dependent claim 4, which is representative of claims 16 and 24 with regard 
to similarly recited subject matter, Larsen does not teach or suggest matching the Web page field 
identifier to an entry field identifier located in the Web page or inserting the user input into a field 
associated with the entry field identifier. The Final Office Action alleges that Larsen teaches these 
features at column 17, lines 46-56 and in the Abstract, lines 7-11, which reads as follows: 
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said matching means being capable of matching said uniquely identified form template data 
fields to said common group information such as to allow matches to be verified by said entity 
using said data processing system, 

said uniquely identified form template data fields which are verifiably matched to said 
common group information becoming common form fields stored in said database. 
(Column 17, Lines 46-50, Larsen) 

The data processing system retrieves tagged information previously entered and stored in a 
database, and automatically inserts the data in similarly tagged imcompleted fields of any 
niunber and variety of forms. 
(Abstract, Lines 7-11, Larsen) 

In the first section, Larsen teaches that data fields in a uniquely identified form template are 

matched to common group information in order to allow an entity to verify the matches. In 

addition, data fields in a uniquely identified form template that are verified become common form 

fields that are stored in the database. In the second section, Larsen teaches that tagged information 

previously entered and stored in the database is retrieved and inserted in similarly tagged 

uncompleted fields of any form. However, neither of the above sections teaches nor suggests that 

the Web page field identifier is matched to an entry identifier located in the Web page. In Larsen, 

the data fields are matched to common group information for verification by an entity. The data 

fields are not matched to an entry identifier located in a Web page. Nowhere in the reference does 

Larsen teach or suggest an entry identifier that is located in a Web page. In addition, Larsen teaches 

that data is inserted in similarly tagged imcompleted fields of any form. Thus, Larsen only inserts 

data to the uncompleted field if the tag of the uncompleted field is similar to the tag that is retrieved 

fi*om the database. Larsen does not teach that the data is inserted into a field with an entry field 

identifier that matches the Web page field identifier. Therefore, Larsen does not teach or suggest 

the features of claims 4, 16 and 24. 

Grouping: riflims 17, and 2^ 

With regard to dependent claim 5, which is representative of claims 17 and 25 with regard 
to similarly recited subject matter, Larsen does not teach sending the Web page identifier to the 
directory server fi-om the background application running on the client device or receiving the user 
input and Web page field identifier fi-om the directory server in response to sending the Web page 
identifier fi-om the background application on the client device. The Final Office Action alleges 
that Larsen teaches these features at column 3, lines 64-67 and column 4, lines 3-25, which reads as 
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follows: 



The information is then transferred over the network to the Form Parser (13), which is a 
network server. The Form Parser (13) submits the request for the form and inputted data to the 
Form Database (3). 
(Column 3, lines 64-67, Larsen) 

The Form Builder (14) is a computer processor that gathers all the previously stored data 
associated with the user's request from the relational database and separates PDF data from 
Non PDF data. The Non PDF data is stored in a copy of the completed form at the Completed 
Form (18) storage. The rest of the data, which is all PDF data, makes up the PDF File (15), and 
is sent to the PDF Merger (7). 

The PDF Merger (7), a computer that uses PDF Merger by Digital Apps, Adobe PDF fill 
software, or other PDF merge software well known to those skilled in the art, completes the 
form by merging the PDF File (15) with an Empty Adobe PDF File (16), which is the stored 
form template that was previously identified with the form being filled out. The filled out PDF 
file is then stored in the Completed Form (18) storage where it can be viewed at a later time. 
The fiill file consisting of the complete PDF form and the Non PDF data is also sent to the 
Form Send (19) server. 

The Form Send (19) server sends the file back over the network to an Extemal Entity (1) 
that has need to the information submitted by the Web User (10). The Extemal Entity (1) 
processes the information and stores the information for later retrieval in its Data Store (11). 
(Column 4, lines 3-25, Larsen) 

In the first section, Larsen teaches a Form Parser that submits the request for a form and 

input data to a Form Database. In the second section, Larsen teaches a Form Builder that retrieves 

stored data from a relational database and separates PDF data from non-PDF data. The PDF data is 

sent to the PDF Merger, which merges the PDF data with an empty PDF file. The filled out PDF 

file is then stored in the Completed Form storage along with the Non PDF data to be sent to the 

Form Send server. The Form Send server sends the fiiU file back to the Extemal Entity (Company), 

which processes the information submitted by the user and stores the information for later retrieval. 

However, neither of the above sections teaches or suggests sending a Web page identifier to the 

directory server from the background application running on the client device. As stated in the 

above arguments, Larsen does not teach or suggest any background appUcation running nn the 

rlient dejv\c,a ^ nor does Larsen teach a background application that sends a Web page identifier to 

the directory server. 

As discussed in the arguments presented for claim 1, with the backgroimd application of the 
presently claimed invention that runs on the client device, a user thinks that he or she is visiting a 
Web page in a normal fashion, however, specific fimctions are performed in the background to 
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retrieve user input and Web page field identifier and populate the Web page without the user's 
awareness. Larsen does not teach such a feature as recited in claim 5. Larsen only teaches that the 
user has to request a form that is stored with pre-fiUed fields fi-om the user input. The system of 
Larsen does not perform specific fianctions, such as sending a Web page identifier to the directory 
server in the background without user's request. Since Larsen does not teach sending the Web page 
identifier to the directory server from the background application running on the client device, 
Larsen would not teach receiving the user input and Web page field identifier from the directory 
server in response to sending the Web page identifier from the background application running on 
the client device. Thus, Appellant respectfiiUy submits that Larsen does not teach the specific 
features of claims 5, 17 and 25. 

Grniiping; riaims 6, 18» 2f>, and4fl 

With regard to dependent claim 6, which is representative of claims 1 8, 26, and 40 with 
regard to similarly recited subject matter, Larsen does not teach inserting user input into a field of a 
Web page corresponding to the Web page field identifier. As discussed in the arguments presented 
above for claims 5, 17 and 25, Larsen does not teach receiving user input and a Web page field 
identifier from the directory server in response to sending the Web page identifier from the 
background application running on the client devirft Therefore, Larsen also fails to teach inserting 
data into a field of the Web page that corresponds to a Web page field identifier when read in 
combination with claims 5, 17, 25, and 37. 

Grouping: Claims 7, 27> and 33 

With regard to claim 7, which is representative of claims 27 and 33 with regard to similarly 
recited subject matter, Larsen does not teach that the user input and the Web page field identifier 
are stored in a Web page entry of the directory server identified by a user identifier and a Web page 
identifier. The Final Office Action alleges that Larsen teaches these features at columns 5-15, 
where Larsen teaches a client_id, which is considered as a user identifier, a tag_id and form_id, 
which are all sorts of Web page identifiers, and that the Web page field identifier are stored in a 
Web page entry (the table) of the directory server (database) identified by a user identifier and a 
Web page identifier (user ID and Web page ID). 

However, Appellant respectfiiUy disagrees. At column 1 1, Larsen teaches two tables that 
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are stored in the database: a form_specific_data_ex table and a form_tags table. The 
form_specific_data_ex table includes a reference of form_data_id in the form_data table at column 
9 and a reference of applicant_id in the applicant table at column 6, which includes a cUent_id. 
However, the form_data table and the applicant table are two separate tables that reside in the 
database. They are not residing in a single Web page entry stored in a directory server. Thus, using 
Larsen's system, in order to retrieve the user input and Web page field identifier fi"om the database, 
separate queries have to be sent to the two separate tables. This is contrary to the presently claimed 
invention, which stores the user input and Web page field identifier, a user identifier, and a Web 
page identifier all in a single Web page entry of the directory server. Thus, the presently claimed 
invention has an advantage over Larsen in that upon a retrieval request sent by a user, the user input 
and Web page field identifier may be directly retrieved without having to send separate queries to 
the database. Therefore, Larsen does not teach the features of claims 7, 27 and 33. 

Crniiping! riaims % .15, and .19 

With regard to claim 9, which is representative of claims 35 and 39 with regard to similarly 
recited subject matter, Larsen does not teach that the Web page field identifier is a HyperText 
Mark-up Language tag. The Final Office Action alleges that Larsen teaches these features at 
column 18, lines 42-44, where Larsen teaches the uniquely identified stored form templates are in 
HTML format. However, Larsen does not teach the data fields within the uniquely identified stored 
form templates are HTML tags, as recited in claim 9. As known to a person of ordinary skill in the 
art, a HTML page may include a variety of tag types, for example, a Java Server Page (JSP) tag. 
Nowhere in the reference does Larsen teach or suggest that the data fields within the uniquely 
identified stored form templates are HTML tags. Larsen only teaches that the form templates are in 
HTML format, but mentions nothing about the data fields within the form templates. Therefore, 
Larsen does not teach the features of claims 9, 35, and 39. 

Grouping! Claini 11 

With regard to dependent claim 11, Larsen does not teach that the method is implemented 
using a plug-in application to a Web browser. The Final Office Action alleges that Larsen teaches 
this feature at column 4, lines 1-20, which teaches that a Form Merger which uses PDF merge by 
Digital Apps, Adobe PDF fill software, or other PDF merge software well knovra in the art to 
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complete the form by merging the PDF File with an Empty Adobe PDF File. The Final Office 
Action further alleges that since the Adobe Reader is used to implement Larsen's teaching, Larsen 
teaches a plug-in application to a Web browser. However, the PDF Merger that uses the Adobe 
software resides in a different computer (17) from the Web user's (12). Therefore, the Adobe 
software used is not a plug-in application to a Web browser that is running on the Web user's 
device. Li addition, there is no teaching or suggestion in Larsen that mentions a plug-in to a Web 
browser. Nowhere in the reference does Larsen even mention that the Adobe software is a plug-in 
to a Web browser running on the Web user's device. Therefore, Larsen does not teach that the 
method is implemented using a plug-in application to a Web browser. 

Grouping; Claim 32 

With regard to dependent claim 32, Larsen does not teach receiving, from the backgroimd 
application running on the client device, a Web page identifier identifying a Web page or sending 
the user input and Web page field identifier to the background application running on the client 
device from the directory server. As discussed in the arguments presented above for claims 5,17 
and 25, Larsen does not teach any background application that is running on the client device, let 
alone receiving from the background application a Web page identifier identifying Web page or 
sending the user input and web page field identifier to the background application. At column 3, 
Larsen only teaches that a Web user may request a form over the network and enters information on 
his or her display. However, Larsen does not teach a background application that runs in parallel 
with the display and sends a Web page identifier to a directory server or receives user input and a 
Web page field identifier from the directory server. Therefore, Larsen does not teach the features of 
claim 32. 

Thus, in addition to being dependent on independent claims 1, 13, 21, 29 and 37 the 
dependent claims 2-7, 9, 1 1, 14-18, 22-27, 30-33, 35, 36 and 38-40 are also allowable by virtue of 
their specific recited features. Accordingly, the rejections of claims 2-7, 9, 11, 14-18, 22-27, 30-33, 
35, 36 and 38-40 should be withdrawn. 
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TT, 3f> TI,S,C. 103(3), AllfgffI OhYioiisness, Claims 8, 19, 28 and 34 



The Final Office Action rejects claims 8, 19, 28 and 34 under 35 U.S.C, 103(a) as allegedly 
being unpatentable over Larsen et al.(U.S. Patent No. 6,088,700) in view of Kavner (U.S. Patent 
No. 6,366,947) and in further view of Tomko (U.S. Patent No. 5,790,668). This rejection is 
respectfully traversed. 

With regard to dependent claim 8, the Final Office Action states: 

Referring to claim 8, Larsen as modified has taught where in the user input is stored in the 
directory server (see previous paragraphs.) 

Larsen as modified has not expUcitly taught the user input is encrypted before being stored. 

However, Tomko has taught the input data is encrypted before being stored at the selected 
address (Col 7 lines 53-55. A method to provide encryption to user inputs in order to secure the 
provided information.) 

It would have been obvious to a person with ordinary skill in the art at the time the 
invention was made to modify the teaching of Larsen such that to have the user input encrypted 
before being stored, because a security is provided to Larsen's data communication as taught by 
Tomko. 

A person with ordinary skill in the art would have been motivated to make the modification 
to Larsen in view of Kavner because having the input being encrypted would provide the 
security to the input (see title of Tomko.) 
Final Office Action dated June 28, 2004, page 7. 

As described above, Larsen does not teach sending an instruction to store user input and a 
Web page field identifier in a directory server from a hackgrminH flpplicatior i running on a dient 
He vice or sending a request from the harkgronnd apph'cati on running on the client devioe to the 
directory server to retrieve the user input and corresponding Web page field identifier. Tomko also 
does not teach these features. Tomko only teaches a method for secure handling of data, 
comprising the steps of: acquiring a database of personal identifiers and data by encrypting the data 
with an encryption key and associating the encrypted data with the personal identifier in the 
database; comparing a personal identifier of a given individual with the database and if there is a 
match, obtaining encrypted data associated with the matching personal identifier; obtaining a 
decryption key for the encrypted data by obtaining an encrypted version of decryption key fi'om 
storage and performing decryption on the decryption key utilizing the personal identifier; and 
performing a decryption operation on the encrypted data with the key obtained (Column 1, lines 35- 
54). Nowhere in the reference does Tomko teach or suggest the features of claims 1, 13, 21 and 37. 

In addition, Tomko does not teach that the user input is encrypted before being stored in the 
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dirertnry server ^ as recited in claims 8, 19, 28 and 34. The Final Office Action alleges that Tomko 
teaches these features at column 7, lines 53-55, which reads as follows: 

However, once the profile has been input, it is encrypted with a third public key, 
Pk3, before being stored at the selected address. 
(Column 7, Lines 53-55, Tomko) 

hi the above section, Tomko teaches encrypting profile data that is input by an operator via 
the profile input device with a public key prior to storing the profile data at the selected address of 
the database. Each profile is associated with a user fingerprint entry in the database. Thus, the 
profile input data is secured data that is encrypted with a public key that is stored with a user's 
fingerprint entry in a database. This is contrary to the presently claimed invention, when read in 
combination with claim 1, which encrypts a user input to a Web page via a Web browser prior to 
storing the user input in the directory server. The profile input data of Tomko is user input to a 
fingerprint profile entry of a database, not user input to a Web page. In addition, Tomko's profile 
data is inputted via a profile input device, not a Web browser. Therefore, it would not have been 
obvious to a person of ordinary skill in the art to modify Larsen's teaching to include Tomko in 
order to have input data encrypted before storage, because Tomko's profile input data to a 
fingerprint entry of a database is non-analogous to a user input to a Web page via a Web browser. 

The profile input data, according to Tomko, only corresponds to a user's fingerprint entry in 
a database, and is unrelated to a user input that is entered to a Web page and stored in a directory 
server. Tomko is not concemed with encrypting user input to a Web page prior to storing it in a 
directory server. Tomko is only interested in securing handling of profile data that is stored in an 
entry of a database that includes a user's fingerprint. Therefore, a person of ordinary skill in the art 
would not be led to take the description of encrypting the profile input data for storage in a 
fingerprint entry of a database and apply it to encrypt user jnput to a Web page via a Web browser 
prior to storing the user input to a directory server, without the previous disclosure of the Appellant. 

hi addition, the Final Office Action alleges that a person of ordinary skill in the art would 
have been motivated to make the modification to Larsen because having the input being encrypted 
would provide security to the input. However, there is no teaching or suggestion in either Larsen or 
Tomko to encrypt user input to a Web page via a Web browser prior to storing the user input in the 
directory server. Larsen is only concemed with providing a tool to allow user to complete multiple 
forms for multiple companies or government agencies. Larsen does not describe or suggest any 
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mechanism for encrypting the user input prior to transferring over the network to the Form Parser. 
Tomko also does not teach or suggest encrypting user input to a Web page via a Web browser prior 
to storing the user input in the directory server. Tomko only teaches encrypting profile input data 
that corresponds to a user's fingerprint entry in a database via a profile input device. Tomko is not 
concemed with encrypting user input to a Web page via a Web browser. Therefore, the motivation 
is not supported in either of Larsen or Tomko. One of ordinary skill in the art, being presented with 
only Larsen and Tomko and not having any prior knowledge of Appellant's claimed invention, 
would not have found any reason to combine the references and modify them in the particular 
manner that would be necessary to arrive at encrypting user input to a Web page via a Web browser 
prior to storing the user input to a directory server. 

Furthermore, even if a person of an ordinary skill in the art is to combine Larsen and 
Tomko 's teaching, the result would not reach the presently claimed invention. The result of 
combination would be encrypting user input to a Web form prior to storing the user input to an 
entry that corresponds to the user's fingerprint in a database. The result would not be encrypting a 
user input to a Web page via a Web browser prior to storing the user input in a directory server. 
Therefore, a person of ordinary skill in the art would not have been motivated to modify Larsen to 
include Tomko 's teaching simply because the combination would still not teach or suggest the 
presently claimed invention. 

Thus, in view of the above. Appellant respectfully submits that neither Larsen nor 
Tomko, either alone or in combination, teach or suggest the specific features of dependent claim 
8. Since dependent claims 19, 28 and 34 are rejected on the same rationale as claim 8, neither 
Larsen nor Tomko teach or suggest the specific features of claims 19, 28 and 34. Therefore, 
Appellant respectfully requests withdrawal of the rejection of dependent claims 8, 19, 28 and 34 
under 35 U.S.C. § 103(a). 

IIL IS TLS.r. lOira^ AllPgeH Ohvinnsnf>ss, riaims in and 16 

The Final Office Action rejects claims 10 and 36 under 35 U.S.C. 103(a) as being 
allegedly unpatentable over Larsen et al. (U.S. Patent No. 6,088,700) in view of Kavner (U.S. 
Patent No. 6,366,947) and in fiirther view of Call (U.S. Patent No. 6,154,738). This rejection is 
respectfully traversed. 
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With regard to dependent claim 10, the Final Office Action states: 

Referring to claim 10, Larsen as modified has not taught the directory server in 
claim 1, however, Larsen as modified has not explicitly taught wherein the directory 
server is an LDAP server. 

However, Call has taught that a LDAP server may be advantageously employed to 
store "entries". . . (Col 20 lines 27-Col 21 lines 4; which show that LDAP server could be 
also viewed as a directory server.) 

It would have been obvious to a person with ordinary skill in the art at the time the 
invention was made to modify the teaching of Larsen in view of Kavner such that to have 
the directory server to be the LDAP server, because LDAP server is ateady well known 
in the art to be a directory server as being developed at the University of Michigan and 
later further developed by Netscape Communication Corp. provides both access and 
update capabilities. (Col 20, lines 30-34.) 

A person with ordinary skill in the art would have been motivated to make the 
modification to Larsen because LDAP is not a newly invented server, which is already 
known in the art. 
Final Office Action dated November 20, 2003, page 7. 

As described above, neither Larsen nor Kavner teach or suggest sending an instruction to 
store user input and Web page field identifier in a directory server fi-om a background application 
running on a client device or sending a request from the harkground apph'catinn running on the 
dient Heviee to the directory server to retrieve the user input and corresponding Web page field 
identifier. Call also does not teach these features. Call teaches a method and apparatus for 
disseminating, over the Litemet, product information produced and maintained by product 
manufacturers using existing universal product codes (bar codes) as access keys. 

A cross-referencing resource, according to Call, may take the form of an independent 
HTTP server, an LDAP directory server, or the existing Internet Domain Name Service (DNS), 
receives Internet request messages containing all or part of a universal product code and retums 
the Internet address at which information about the identified product, or the manufacturer of that 
product, may be obtained. By using preferred Web data storage formats which conform to XML, 
XLS, XLink, Xpointer and RDF specifications, product information may be seamlessly 
integrated with information from other sources. A "web register" module can be employed to 
provide an internal interface between a shared sales Intemet server and an otherwise conventional 
inventory control system, and operates in conjunction with the cross-referencing server to 
provide detailed product information to Intemet shoppers who may purchase goods fi-om existing 
stores via the Intemet. 

Thus, Call only teaches a cross referencing server that receives messages for a particular 
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product, which includes corresponding universal product code. The cross referencing server then 
returns the Internet address of the particular manufacturer's server which then makes the desired 
product information available to the user. Call does not teach that the cross referencing server 
sends or receives user input and Web page field identifier to or from a background application 
running on a client device. Call also does not teach storing user input and a Web page field 
identifier in a directory server. 

The Final Office Action alleges that Call teaches the features of claims 10 and 36 at 
column 20, line 27 to column 21, line 4, which reads as follows: 

The Internet LDAP protocol may be used to advantage to implement the product code 
translation process. This protocol, developed at the University of Michigan and later further 
developed by Netscape Communication Corp. provides both access and update capabilities, 
allowing directory information to be created and managed as well as queried. LDAP is an 
open Intemet standard, produced by the Internet Engineering Task Force (IETF), the same 
body responsible for creating TCP/IP, the Intemet domain name service (DNS), and the 
hypertext transport protocol (HTTP). The LDAP protocol is defined in RFCs 1777 and 1778 
and informational documentation is further provided in RFC 1 823. The use of LDAP to 
provide directory lookup services via the Intemet is further detailed in the literature. See, for 
example. Implementing LDAP by Mark Wilcox (Wrox Press- 1999) and LDAP - 
Programming Directory Enabled Applications with Lightweight Directory Access Protocol 
by Tim Howes and Mark Smith (Mcmillan Technology Series - 1997). Operational LDAP 
server software may be purchased from a variety of sources, and includes the 'TSTetscape 
Directory Server" marketed by the Netscape Communications Corporation. 

An LDAP server may be advantageously employed to store "entries", each of which is 
uniquely identified by a distinguished name (DN) which may take the form of the company 
code portion of the universal product mde ^ creating a "flat namespace" in a single tree level 
structure, with the remainder of the entry including a string specifying the URL of the server 

resoiirre from which information ahnnt proHnrts assigned that nompany eoHe may he found . 
In one arrangement, an online merchant's server may send a request to a remote directory 
server using the LDAP protocol to obtain the URL at which information about a specific 
product is available. Next, the merchant's server could again use the LDAP protocol to fetch 
information about a specific product designated by the remainder of the universal product 
code from a second LDAP server at the URL specified by the first server, the second LDAP 
server being operated by the product manufacturer to store the URL at which data describing 
particular products is stored. The actual product data may advantageously be stored as XML 
"documents" as discussed later, (emphasis added) 
(Column 20, Line 27-Column 21, Line 4, Call) 

hi the above section. Call teaches using a LDAP server to store entries, each of the entries 

contains a company code portion of the universal product code sent by the user and a URL from 

which information about products assigned that company code may be found. However, when 

read in combination of claims 1 and 29, Call does not teach the LDAP server as a directory 
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server that stores user input entered by a user to a Web page via a Web browser and 
corresponding Web page field identifier. While Call teaches LDAP server as a directory server 
that stores entries, the entries does not include any user input or Web page field identifier. 

To the contrary, each of the entries in Call includes a company code portion of a universal 
product code of a product selected by a user and a URL that identifies a source of information for 
the product. Neither portion of the entry as taught by Call includes user input that is entered to a 
Web page via a Web browser or corresponding Web page field identifier. An example of user 
input to a Web page, as described on page 13 of the presently claimed specification, is a social 
security number that is associated with a Web page field identifier <socsec>. Neither the product 
code of the universal product code nor the URL as taught by Call represent such user input to a 
Web page or corresponding Web page field identifier. Therefore, Call does not teach the same 
LDAP directory server that is recited in claims 10 and 36. 

The Final Office Action fiirther alleges that it would have been obvious to a person with 
ordinary skill in the art at the time the invention was made to modify the teachings of Larsen to 
have the directory server to be the LDAP server, because the LDAP server is already well known 
in the art to be a directory server as being developed at the University of Michigan and later 
further developed by Netscape Communication Corp., which provides both access and update 
capabilities. Appellant respectfully disagrees. While LDAP protocol is well known in the art to 
be used as a directory server, the LDAP server, as taught by Call, is not used in a manner that 
would be necessary to arrive at an LDAP server of the presently claimed invention, which stores 
user input and Web page field identifier. Therefore, a person of ordinary skill in the art would 
not have been led to modify Larsen to include the LDAP server of Call to store user input and 
Web page field identifiers, simply because there is no teaching or suggestion in either Larsen or 
Call of an LDAP directory server that stores user input and Web page field identifiers in an 
LDAP directory server. 

Furthermore, the Final Office Action alleges that a person of ordinary skill in the art 
would have been motivated to make the modification to Larsen because LDAP is not a newly 
invented server, which is already known in the art. However, while a LDAP server is well 
knovm as a directory server that stores entries, there is no suggestion or teaching in either Larsen 
or Call that supports the motivation that the entries of an LDAP directory server include user 
input and a Web page field identifier. Larsen is only concerned with providing a tool that allows 
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a Web user to complete multiple Web forms for multiple companies. The Web user transfers 
information over the network to a Form Parser, which sends the request and inputted data to a 
Form Parser. Larsen does not suggest that a need exists for an LDAP server to store the inputted 
data. Call is only concerned with using an LDAP directory server to store a company code 
portion of a universal product code of a product selected by a user and a URL that contains 
information for the product assigned with the company code. Call does not suggest storing user 
input from a Web user to the LDAP server. Therefore, a person of ordinary skill in the art would 
not have been motivated to modify or combine Larsen and Call, because the motivation of 
storing user input and Web page field identifier in an LDAP directory server is simply not 
supported in either of the references. 

In view of the above. Appellant respectfully submits that neither Larsen nor Call, either 
alone or in combination, teach or suggest the specific features of dependent claim 10. Since 
dependent claim 36 is rejected on the same rationale as claim 10, neither Larsen nor Call teach or 
suggest the specific features of claim 36. Therefore, Appellant respectfully requests withdrawal 
of the rejection of dependent claims 10 and 36 under 35 U.S.C. § 103(a). 

IV. Summary 

In summary, Larsen, Kavner, Tomko and Call fail to teach or suggest the specific features 
of the present invention. There is nothing in Larsen, Kavner, Tomko or Call that teaches or 
suggests sending an instruction to store a user input and a Web page field identifier in a directory 
server from a background application running on a client device or sending a request from a 
background application running on the client device to retrieve user input and the corresponding 
Web page field identifier from the directory server. In addition, there is nothing in Larsen, 
Kavner, Tomko or Call that teaches or suggests encrypting the user input to a Web page via a 
Web browser prior to storing the user input in a directory server or an LDAP directory server that 
stores user input to a Web page. 
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In view of the above, Appellant respectfully submit that claims 1-11, 13-19, and 21-40 define 
over the prior art of record, Larsen, Kavner, Tomko, and Call. Appellant therefore respectfully 
requests the Board of Patent Appeals and Interferences to overturn the rejection of claims 1-11, 
13-19, and 21-40 under 35 U.S.C. 103(a). 
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The text of the claims involved in the appeal are: 

1 . A method for maintaining state information for Web pages, comprising: 
receiving user input to a Web page via a Web browser at a client device; 

sending an instruction to store user input and a Web page field identifier in a directory 
server from a background application running on the client device; 

storing the user input and a corresponding Web page identifier in a directory server; and 
in response to receiving a user request, via the Web browser, for the Web page, sending a 
request fi"om the background application running on the client device to the directory server to 
retrieve the user input and corresponding Web page field identifier, wherein the user input and 
corresponding Web page field identifier are retrieved from the directory server. 

2. The method of claim 1, wherein the user input and Web page field identifier are specific 
to a particular Web page. 

3. The method of claim 1 , wherein the user input and Web page field identifier are common 
to a plurality of Web pages. 

4. The method of claim 1 further comprising: 

matching the Web page field identifier to an entry field identifier located in the Web 
pages; and 

inserting the user input into a field associated with the entry field identifier. 
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5. The method of claim 1, further comprising: 

receiving a Web page retrieval request having a Web page identifier identifying the Web 
page from a Web browser running on the client device; 

sending the Web page identifier to the directory server from the background application 
running on the client device; and 

receiving the user input and Web page field identifier fi"om the directory server in 
response to sending the Web page identifier from the background application running on the 
client device. 

6. The method of claim 5, further comprising inserting the user input into a field of the Web 
page corresponding to the Web page field identifier. 

7. The method of claim 1 , wherein the user input and the Web page field identifier are 
stored in a Web page entry of the directory server identified by a user identifier and a Web page 
identifier. 

8. The method of claim 1, wherein the user input is encrypted before being stored in the 
directory server. 

9. The method of claim 1 , wherein the Web page field identifier is a HyperText Mark-up 
Language tag. 

10. The method of claim 1, wherein the directory server is an LDAP server. 
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1 1 . The method of claim 1 , wherein the method is implemented using a plug-in application to 
a Web browser. 

13. A computer program product in a computer readable medium for maintaining state 
information for Web pages, comprising: 

first instructions for receiving user input to a Web page via a Web browser at a client 

device; 

second instructions for sending an instruction to store user input and a Web page field 
identifier in a directory server fi-om a background application running on the client device; 

third instructions for storing the user input and a corresponding Web page identifier in a 
directory server, and 

fourth instructions for sending a request fi-om the background application running on the 
client device to the directory server to retrieve the user input and corresponding Web page field 
identifier, in response to receiving a user request, via the Web browser, for the Web page, 
wherein the user input and corresponding Web page field identifier are retrieved from the 
directory server. 

14. The computer program product of claim 13, wherein the user input and Web page field 
identifier are specific to a particular Web page. 

15. The computer program product of claim 13, wherein the user input and Web page field 
identifier are common to a plurality of Web pages. 
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16. The computer program product of claim 13, further comprising: 

fifth instructions for matching the Web page field identifier to an entry field identifier 
located in the Web page; and 

sixth instructions for inserting the user input into a field associated with the entry field 
identifier. 

17. The computer program product of claim 13, further comprising: 

fifth instructions for receiving a Web page retrieval request having a Web page identifier 
identifying the Web page fi*om a Web browser running on the chent device; 

sixth instructions for sending the Web page identifier to the directory server fi:'om the 
background apphcation running on the cUent device; and 

seventh instructions for receiving the user input and Web page field identifier fi"om the 
directory server in response to sending the Web page identifier fi^om the background application 
ruiming on the client device. 

18. The computer program product of claim 17, fiirther comprising eighth instructions for 
inserting the user input into a field of the Web page corresponding to the Web page field 
identifier. 

19. The computer program product of claim 13, fiirther comprising third instructions for 
encrypting the user input before storing the user input in the directory server. 
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21 . An apparatus for maintaining state information for Web pages, comprising: 
a processor; 

an input device coupled to the processor; and 

a network interface coupled to the processor and to a network, wherein the processor 
receives user input to a Web page via a Web browser at a client device, sends an instruction from 
a background application running on the client device to a directory server, via the network 
interface, to store the user input and a corresponding Web page field identifier in the directory 
server, and sends a request from the background application running on the client device to the 
directory server to retrieve the user input and corresponding Web page field identifier, in 
response to receiving a user request via the Web browser, for the Web page, wherein the user 
input and corresponding Web page field identifier are retrieved from the directory server. 

22. The apparatus of claim 21, wherein the user input and Web page field identifier are 
specific to a particular Web page. 

23. The apparatus of claim 21, wherein the user input and Web page field idenfifier are 
common to a plurality of Web pages. 

24. The apparatus of claim 21, wherein the processor matches the Web page field identifier to 
an entry field identifier located in the Web page and inserts the user input into a field associated 
with the entry field identifier. 
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25. The apparatus of claim 21, wherein the processor receives a Web page retrieval request 
having a Web page identifier identifying the Web page from a Web browser running on the client 
device via the input device, sends the Web page identifier from the background application 
running on the client device to the directory server via the network interface, and receives the 
user input and Web page field identifier from the directory server in response to sending the Web 
page identifier from the background application running on the client device via the network 
interface. 

26. The apparatus of claim 25, wherein the processor inserts the user input into a field of the 
Web page corresponding to the Web page field identifier. 

27. The apparatus of claim 21, wherein the user input and the Web page field identifier are 
stored in a Web page entry of the directory server identified by a user identifier and a Web page 
identifier. 

28. The apparatus of claim 21, wherein the processor encrypts the user input before the user 
input is stored in the directory server. 

29. A method, in a directory server, for maintaining state information for Web pages, 
comprising: 

receiving user input to a Web page from a background application running on a client 
device; and 
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storing the user input and a corresponding Web page field identifier received from the 
background application running on the client device in the directory server, wherein the user 
input and corresponding Web page field identifier are downloaded from the directory server to 
the client device in response to a user request for a Web page. 

30. The method of claim 29, wherein the user input and Web page field identifier are specific 
to a particular Web page. 

3 1 . The method of claim 29, wherein the user input and Web page field identifier are 
common to a plurality of Web pages. 

32. The method of claim 29, ftirther comprising: 

receiving, from the background application running on the client device, a Web page 
identifier identifying the Web page; 

retrieving the user input and Web page field identifier in response to receiving the Web 
page identifier; and 

sending the user input and Web page field identifier to the background application 
running on the client device from the directory server. 

33. The method of claim 29, wherein the user input and the Web page field identifier are 
stored as a Web page entry identified by a user identifier and a Web page identifier. 

34. The method of claim 29, wherein the user input is encrypted before being stored. 
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35. The method of claim 29, wherein the Web page field identifier is a HyperText Mark-up 
Language tag. 

36. The method of claim 29, wherein the directory server is an LDAP server. 

37. A method in a data processing system for maintaining state information for a Web page, 
the method comprising: 

receiving a user input to the Web page and an identifier associated with the user input via 
a Web browser at a client; 

sending an instruction from a background application running on the client to store user 
input to the Web page and the identifier associated with the user input; 

storing the user input to the Web page and the identifier associated with the user input in 
a server; and 

responsive to a subsequent request via the Web page, sending a request from the 
background application running on the client to the server to retrieve the user input and the 
identifier from the server. 

38. The method of claim 37, wherein the server is a directory server. 

39. The method of claim 37, wherein the identifier is a tag from the Web page. 
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The method of claim 37, further comprising: 

placing the user input retrieved from the server in the Web page using the identifier. 
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There is no evidence to be presented. 
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There are no related proceedings. 
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